Aminet 1 (Walnut Creek)/Aminet - June 1993 [Walnut Creek].iso/aminet/gfx/show/mpeg_bin_play201.lha/mpeg/MPEG.faq

Text File | 2001-02-03 | 33KB | 756 lines

        THE MPEG-FAQ         [Version 1.0 - 20. November 1992]
        ======================================================
        PHADE SOFTWARE Leibnizstr. 30, 1000 Berlin 12, GERMANY
        Inh. Frank Gadegast            Fon/Fax: [phone]

        [e-mail]

===============================================================================

This is my summary about MPEG, nearly 3 month ago I asked for information
about MPEG, and these are the results:

This summary is devided in seven parts:

 I    |  WHAT IS MPEG ?
 II   |  PROFESSIONAL SOFTWARE
 III  |  PUBLIC-DOMAIN SOFTWARE
 IV   |  MAILBOX-ACCESS
 V    |  FTP-ACCESS (PD)
 VI   |  MAIL-ACCESS (PD-Software and movies)
 VII  |  RETRIEVED MAIL
 VIII |  NEWS

I add my comments in brackets [], lines (---- or ====) seperate the chapters.

Please try and find out more information yourself. I had enough to do by
getting and preparing this information. And only bother me with file-request if
its not possible for you to get it somewhere else !!!

Please send any additional information via fax or e-mail. The fax is only
reachable between Mo.-Fr. from 10.00-13.00 and from 15.00-18.30 german time.


    Phade (Frank Gadegast)

===============================================================================
 I | WHAT IS MPEG ?
===================

From comp.compression Mon Oct 19 15:38:38 1992
~Sender: [e-mail]
Author: Mark Adler <[e-mail]>.

[71] Introduction to MPEG (long)
       What is MPEG?
       Does it have anything to do with JPEG?
       Then what's JBIG and MHEG?
       What has MPEG accomplished?
       So how does MPEG I work?
       What about the audio compression?
       So how much does it compress?
       What's phase II?
       When will all this be finished?
       How do I join MPEG?
       How do I get the documents, like the MPEG I draft?

-------------------------------------------------------------------------------

~Subject: [71] Introduction to MPEG (long)

Q. What is MPEG?
A. MPEG is a group of people that meet under ISO (the International
   Standards Organization) to generate standards for digital video
   (sequences of images in time) and audio compression.  In particular,
   they define a compressed bit stream, which implicitly defines a
   decompressor.  However, the compression algorithms are up to the
   individual manufacturers, and that is where proprietary advantage
   is obtained within the scope of a publicly available international
   standard.  MPEG meets roughly four times a year for roughly a week
   each time.  In between meetings, a great deal of work is done by
   the members, so it doesn't all happen at the meetings.  The work
   is organized and planned at the meetings.

Q. So what does MPEG stand for?
A. Moving Pictures Experts Group.

Q. Does it have anything to do with JPEG?
A. Well, it sounds the same, and they are part of the same subcommittee
   of ISO along with JBIG and MHEG, and they usually meet at the same
   place at the same time.  However, they are different sets of people
   with few or no common individual members, and they have different
   charters and requirements.  JPEG is for still image compression.

Q. Then what's JBIG and MHEG?
A. Sorry I mentioned them. Ok, I'll simply say that JBIG is for binary
   image compression (like faxes), and MHEG is for multi-media data
   standards (like integrating stills, video, audio, text, etc.).

Q. Ok, I'll stick to MPEG.  What has MPEG accomplished?
A. So far (as of January 1992), they have completed the "Committee
   Draft" of MPEG phase I, colloquially called MPEG I.  It defines
   a bit stream for compressed video and audio optimized to fit into
   a bandwidth (data rate) of 1.5 Mbits/s.  This rate is special
   because it is the data rate of (uncompressed) audio CD's and DAT's.
   The draft is in three parts, video, audio, and systems, where the
   last part gives the integration of the audio and video streams
   with the proper timestamping to allow synchronization of the two.
   They have also gotten well into MPEG phase II, whose task is to
   define a bitstream for video and audio coded at around 3 to 10
   Mbits/s.

Q. So how does MPEG I work?
A. First off, it starts with a relatively low resolution video
   sequence (possibly decimated from the original) of about 352 by
   240 points by 30 frames/s (US--different numbers for Europe),
   but original high (CD) quality audio.  The images are in color,
   but converted to YUV space, and the two chrominance channels
   (U and V) are decimated further to 176 by 120 pixels.  It turns
   out that you can get away with a lot less resolution in those
   channels and not notice it, at least in "natural" (not computer
   generated) images.

   The basic scheme is to predict motion from frame to frame in the
   temporal direction, and then to use DCT's (discrete cosine
   transforms) to organize the redundancy in the spatial directions.
   The DCT's are done on 8x8 blocks, and the motion prediction is
   done in the luminance (Y) channel on 16x16 blocks.  In other words,
   given the 16x16 block in the current frame that you are trying to
   code, you look for a close match to that block in a previous or
   future frame (there are backward prediction modes where later
   frames are sent first to allow interpolating between frames).
   The DCT coefficients (of either the actual data, or the difference
   between this block and the close match) are "quantized", which
   means that you divide them by some value to drop bits off the
   bottom end.  Hopefully, many of the coefficients will then end up
   being zero.  The quantization can change for every "macroblock"
   (a macroblock is 16x16 of Y and the corresponding 8x8's in both
   U and V).  The results of all of this, which include the DCT
   coefficients, the motion vectors, and the quantization parameters
   (and other stuff) is Huffman coded using fixed tables.  The DCT
   coefficients have a special Huffman table that is "two-dimensional"
   in that one code specifies a run-length of zeros and the non-zero
   value that ended the run.  Also, the motion vectors and the DC
   DCT components are DPCM (subtracted from the last one) coded.

Q. So is each frame predicted from the last frame?
A. No.  The scheme is a little more complicated than that.  There are
   three types of coded frames.  There are "I" or intra frames.  They
   are simply a frame coded as a still image, not using any past
   history.  You have to start somewhere.  Then there are "P" or
   predicted frames.  They are predicted from the most recently
   reconstructed I or P frame.  (I'm describing this from the point
   of view of the decompressor.)  Each macroblock in a P frame can
   either come with a vector and difference DCT coefficients for a
   close match in the last I or P, or it can just be "intra" coded
   (like in the I frames) if there was no good match.

   Lastly, there are "B" or bidirectional frames.  They are predicted
   from the closest two I or P frames, one in the past and one in the
   future.  You search for matching blocks in those frames, and try
   three different things to see which works best.  (Now I have the
   point of view of the compressor, just to confuse you.)  You try using
   the forward vector, the backward vector, and you try averaging the
   two blocks from the future and past frames, and subtracting that from
   the block being coded.  If none of those work well, you can intra-
   code the block.

   The sequence of decoded frames usually goes like:

   IBBPBBPBBPBBIBBPBBPB...

   Where there are 12 frames from I to I (for US and Japan anyway.)
   This is based on a random access requirement that you need a
   starting point at least once every 0.4 seconds or so.  The ratio
   of P's to B's is based on experience.

   Of course, for the decoder to work, you have to send that first
   P *before* the first two B's, so the compressed data stream ends
   up looking like:

   0xx312645...

   where those are frame numbers.  xx might be nothing (if this is
   the true starting point), or it might be the B's of frames -2 and
   -1 if we're in the middle of the stream somewhere.

   You have to decode the I, then decode the P, keep both of those
   in memory, and then decode the two B's.  You probably display the
   I while you're decoding the P, and display the B's as you're
   decoding them, and then display the P as you're decoding the next
   P, and so on.

Q. You've got to be kidding.
A. No, really!

Q. Hmm.  Where did they get 352x240?
A. That derives from the CCIR-601 digital television standard which
   is used by professional digital video equipment.  It is (in the US)
   720 by 243 by 60 fields (not frames) per second, where the fields
   are interlaced when displayed.  (It is important to note though
   that fields are actually acquired and displayed a 60th of a second
   apart.)  The chrominance channels are 360 by 243 by 60 fields a
   second, again interlaced.  This degree of chrominance decimation
   (2:1 in the horizontal direction) is called 4:2:2.  The source
   input format for MPEG I, called SIF, is CCIR-601 decimated by 2:1
   in the horizontal direction, 2:1 in the time direction, and an
   additional 2:1 in the chrominance vertical direction.  And some
   lines are cut off to make sure things divide by 8 or 16 where
   needed.

Q. What if I'm in Europe?
A. For 50 Hz display standards (PAL, SECAM) change the number of lines
   in a field from 243 or 240 to 288, and change the display rate to
   50 fields/s or 25 frames/s.  Similarly, change the 120 lines in
   the decimated chrominance channels to 144 lines.  Since 288*50 is
   exactly equal to 240*60, the two formats have the same source data
   rate.

Q. You didn't mention anything about the audio compression.
A. Oh, right.  Well, I don't know as much about the audio compression.
   Basically they use very carefully developed psychoacoustic models
   derived from experiments with the best obtainable listeners to
   pick out pieces of the sound that you can't hear.  There are what
   are called "masking" effects where, for example, a large component
   at one frequency will prevent you from hearing lower energy parts
   at nearby frequencies, where the relative energy vs. frequency
   that is masked is described by some empirical curve.  There are
   similar temporal masking effects, as well as some more complicated
   interactions where a temporal effect can unmask a frequency, and
   vice-versa.

   The sound is broken up into spectral chunks with a hybrid scheme
   that combines sine transforms with subband transforms, and the
   psychoacoustic model written in terms of those chunks.  Whatever
   can be removed or reduced in precision is, and the remainder is
   sent.  It's a little more complicated than that, since the bits
   have to be allocated across the bands.  And, of course, what is
   sent is entropy coded.

Q. So how much does it compress?
A. As I mentioned before, audio CD data rates are about 1.5 Mbits/s.
   You can compress the same stereo program down to 256 Kbits/s with
   no loss in discernable quality.  (So they say.  For the most part
   it's true, but every once in a while a weird thing might happen
   that you'll notice.  However the effect is very small, and it takes
   a listener trained to notice these particular types of effects.)
   That's about 6:1 compression.  So, a CD MPEG I stream would have
   about 1.25 MBits/s left for video.  The number I usually see though
   is 1.15 MBits/s (maybe you need the rest for the system data
   stream).  You can then calculate the video compression ratio from
   the numbers here to be about 26:1.  If you step back and think
   about that, it's little short of a miracle.  Of course, it's lossy
   compression, but it can be pretty hard sometimes to see the loss,
   if you're comparing the SIF original to the SIF decompressed.  There
   is, however, a very noticeable loss if you're coming from CCIR-601
   and have to decimate to SIF, but that's another matter.  I'm not
   counting that in the 26:1.

   The standard also provides for other bit rates ranging from 32Kbits/s
   for a single channel, up to 448 Kbits/s for stereo.

Q. What's phase II?
A. As I said, there is a considerable loss of quality in going from
   CCIR-601 to SIF resolution.  For entertainment video, it's simply
   not acceptable.  You want to use more bits and code all or almost
   all the CCIR-601 data.  From subjective testing at the Japan
   meeting in November 1991, it seems that 4 MBits/s can give very
   good quality compared to the original CCIR-601 material.  The
   objective of phase II is to define a bit stream optimized for these
   resolutions and bit rates.

Q. Why not just scale up what you're doing with MPEG I?
A. The main difficulty is the interlacing.  The simplest way to extend
   MPEG I to interlaced material is to put the fields together into
   frames (720x486x30/s).  This results in bad motion artifacts that
   stem from the fact that moving objects are in different places
   in the two fields, and so don't line up in the frames.  Compressing
   and decompressing without taking that into account somehow tends to
   muddle the objects in the two different fields.

   The other thing you might try is to code the even and odd field
   streams separately.  This avoids the motion artifacts, but as you
   might imagine, doesn't get very good compression since you are not
   using the redundancy between the even and odd fields where there
   is not much motion (which is typically most of image).

   Or you can code it as a single stream of fields.  Or you can
   interpolate lines.  Or, etc. etc.  There are many things you can
   try, and the point of MPEG II is to figure out what works well.
   MPEG II is not limited to consider only derivations of MPEG I.
   There were several non-MPEG I-like schemes in the competition in
   November, and some aspects of those algorithms may or may not
   make it into the final standard for entertainment video compression.

Q. So what works?
A. Basically, derivations of MPEG I worked quite well, with one that
   used wavelet subband coding instead of DCT's that also worked very
   well.  Also among the worked-very-well's was a scheme that did not
   use B frames at all, just I and P's.  All of them, except maybe one,
   did some sort of adaptive frame/field coding, where a decision is
   made on a macroblock basis as to whether to code that one as one
   frame macroblock or as two field macroblocks.  Some other aspects
   are how to code I-frames--some suggest predicting the even field
   from the odd field.  Or you can predict evens from evens and odds
   or odds from evens and odds or any field from any other field, etc.

Q. So what works?
A. Ok, we're not really sure what works best yet.  The next step is
   to define a "test model" to start from, that incorporates most of
   the salient features of the worked-very-well proposals in a
   simple way.  Then experiments will be done on that test model,
   making a mod at a time, and seeing what makes it better and what
   makes it worse.  Example experiments are, B's or no B's, DCT vs.
   wavelets, various field prediction modes, etc.  The requirements,
   such as implementation cost, quality, random access, etc. will all
   feed into this process as well.

Q. When will all this be finished?
A. I don't know.  I'd have to hope in about a year or less.

Q. How do I join MPEG?
A. You don't join MPEG.  You have to participate in ISO as part of a
   national delegation.  How you get to be part of the national
   delegation is up to each nation.  I only know the U.S., where you
   have to attend the corresponding ANSI meetings to be able to
   attend the ISO meetings.  Your company or institution has to be
   willing to sink some bucks into travel since, naturally, these
   meetings are held all over the world.  (For example, Paris,
   Santa Clara, Kurihama Japan, Singapore, Haifa Israel, Rio de
   Janeiro, London, etc.)

Q. Well, then how do I get the documents, like the MPEG I draft?
A. MPEG is a draft ISO standard. It's exact name is ISO CD 11172.
   The draft consists of three parts: System, Video, and Audio. The
   System part (11172-1) deals with synchronization and multiplexing
   of audio-visual information, while the Video (11172-2) and Audio
   part (11172-3) address the video and the audio compression techniques
   respectively.

   You may order it from your national standards body (e.g. ANSI in
   the USA) or buy it from companies like
     OMNICOM
     phone [phone]
     FAX [phone]


===============================================================================
 II.1 | PROFESSIONAL SOFTWARE
=============================

    Xing Technology Corporation
    PO Box 950                                Voice: 805-473-0145
    456 Carpenter Canyon                      FAX:   [phone]
    Arroyo Grande, CA 93420

    Xing products include:

        MPEG Motion video capture/encode and decode.
        JPEG Photo image encode and decode.
        Video capture boards and associated software for both JPEG and MPEG.

        Microsoft Windows Applications, DOS Applications,
            and Software Developers Kits are available for JPEG and MPEG.

    ---------------------------------------------------------------------------

    Check out the latest in Frame Grabber technology, the

                  PC-Hurricane,

    a realtime  true color frame grabber, which can digitize about 500 frames
    in realtime (25 frames/sec) into Extended Memory (32 MBytes).
    So it gives you 20 seconds of full-motion video on the PC.

    These 320 frames can be saved with one command to the harddrive and can then
    be processed to a MPEG file with just one other command.
    You can then join several 20 seconds MPEG clips together to a whole
    MPEG movie with the MPEG utilities.

    PC-Hurricane, only available from Ingenierbuero Gatz & Hartmann, GERMANY.


-------------------------------------------------------------------------------
 II.2 |
-------

    Ingenieurbuero Gatz & Hartmann,

    Fehrbelliner Str. 32, 1000 Berlin 20, GERMANY

    Tel: [phone] or 030-375 55 68
    FAX: [phone] or 030-375 56 55

    email to: [e-mail]


    The MPEG Encoder is available starting from 349.-DM incl. VAT.

    PC-Hurricane, only available from Ingenierbuero Gatz & Hartmann.
    It will be available around December 1992 for a price of 699.-DM
    inclusive 14 %  VAT.

    ---------------------------------------------------------------------------

    MPEG 2.0 for windows3.x is now available !

    It is the digital Video player via a software only solution ! It displays
    in a 320x240 window under win3.x a realtime decompressed digital video !
    Decompression is done only by software and it reaches 30 frames/sec on a
    486 PC ! The new version has a very enhanced picture quality, because the
    compression rate with the encoder can now be adjusted ! The very new thing
    is the WAV-Sound support ! So if you have a soundcard inside your PC [or
    the speaker-drv installed !], you will have a real video-clip with
    accompagning sound !

    They currently sell 3 demo disks with the full featured Player, version
    2.0 and lots of animations on the disks.

    It is availbale for 39.-DM over here in Germany, which is 26 US$.

    ---------------------------------------------------------------------------

    BTW, the encoder still sells for 349.-DM and the MCI-driver for 199.-DM


===============================================================================
 III | PUBLIC-DOMAIN-SOFTWARE
=============================


-------------------------------------------------------------------------------
 III.1 | DOS
------------

    The MPEG-Player 'MPLAY.EXE' from Xing Technologies is included
    in the 'MPEGXING.LZH'-file.


-------------------------------------------------------------------------------
 III.2 | WINDOWS
----------------

    The MPEG-Player 'MPEGXING.LZH' from Xing Technologies.


-------------------------------------------------------------------------------
 III.3 | X-WINDOWS
------------------

    The MPEG-Player 'mpeg-1.0.tar.Z' from Rowe, Patel and Smith at Berkeley.


                      MPEG Video Software Decoder
                    (Version 1.0; Nov 16,1992)

            Lawrence A. Rowe, Ketan Patel, and Brian Smith
     Computer Science Division-EECS, Univ. of Calif. at Berkeley

    This directory contains a public domain MPEG video software
    decoder. The decoder is implemented as a library that will
    take a video stream and display it in an X window. The main
    routine is supplied to demonstrate the use of the decoder
    library. Several dithering algorithms are supplied based on
    the Floyd-Steinberg, ordered dither, and half-toning algorithms
    that tradeoff quality and performance. Neither the library nor
    the main routine handle real-time synchronization or audio streams.

    The decoder implements the standard described in the Committee
    Draft ISO/IEC CD 11172 dated December 6, 1991 which is
    sometimes refered to as "Paris Format." The code has been
    compiled and test on the following platforms:

     HP PA-RISC (HP/UX 8.X, X11R4) (i.e., HP 9000/7XX's)
     Sun Sparc (SunOS 4.X, X11R5)
     DECstation 5000 and Alpha

    If you decide to port the code to a new architecture, please let
    us know so that we can incorporate the changes into our sources.

    This directory contains everything required to build and
    display video. We have included source code, a makefile,
    installation instructions, and a man page. Data files can
    be obtained from the same ftp site this was located in.
    See the INSTALL file for instructions on how to
    compile and run the decoder.

    The data files were produced by XING. XING data does not take
    advantage of P or B frames (ie, frames with motion compensation).
    Performance of the player on XING data is significantly slower
    (half or less) than the performance when motion compensated MPEG
    data is decoded. We are very interested in running the software
    on other MPEG streams.  Please contact us if you have a stream
    that does not decode correctly. Also, please send us new streams
    produced by others that do utilize P and B frames.

    We have established several mailing lists for messages about
    the decoder:

    [e-mail]
       General information on the decoder for everyone interested
       should be sent to this list.  This should become active after
       11/20/92

    [e-mail]
       Requests to join or leave the list should be sent to this
       address. The subject line should contain the single word
       ADD or DELETE.

    [e-mail]
       Problems, questions, or patches should be sent to this address.

    Our future plans include porting the decoder to run on other
    platforms, integrating it into a video playback system that
    supports real-time synchronization and audio streams, and
    further experiments to improve the performance of the
    decoder. Vendors or other organizations interested in supporting
    this research or discussing other aspects of this project should
    contact Larry Rowe at [e-mail].

    ACKNOWLEDGEMENTS:
        We would like to thank the following people for their help:

        Tom Lane of the Independent JPEG Group provided us with
        the basic inverse DCT code used by our player.
        ([e-mail])

        Reid Judd of Sun Microsystems provided advise and assistance.

        Todd Brunhoff of NVR provided advise and assistance.


-------------------------------------------------------------------------------
 III.4 | DATA
-------------


    Several data-files (.gl) are known. See the list below in chapter VI.


===============================================================================
 IV.1 | MAILBOX-ACCESS
======================

    This is the phone number of Xing Technologies' BBS:

    805-473-2680 (2400b) (USA)


-------------------------------------------------------------------------------
 IV.2 |
-------

    These are the phone numbers of Gatz & Hartmann's
    7 line support BBS:

    ++49 30- 462 63 41 (v32bis)
    ++49 30- 462 64 35 (v32bis)
    ++49 30- 462 65 38 (v32bis)
    ++49 30- 462 60 22 (v32 + PEP)
    ++49 30- 462 61 37 (v32)
    ++49 30- 462 62 37 (v32)
    ++49 30- 461 86 50 (v22bis + HST)

    This is the professional Zelator-ACCESS-BBS system with Internet access.
    There will be several new MPEG clips and updates of the GENOA 7900 SVGA board
    drivers, 24 bit ET4000 programing infos,etc... Check it out ! You will enjoy it.
    Just log in with:

    guh

    That means: Gatz und Hartmann.


===============================================================================
 V.1 |  FTP-ACCESS (PD)
=======================

    There is an MPEG archive site at:

      phoenix.oulu.fi (130.231.240.17) in the directory /pub/mpeg

    Here is the current list from /pub/mpeg:

    -rw-r--r--  1 12       10         471502 Sep 13 17:36 MPEGXING.LZH
    -rw-r--r--  1 12       10           1192 Oct  2 21:48 TUTTIF3D.DOC
    -rw-r--r--  1 12       10         502473 Jul 23 21:53 birdisba.mpg
    -rw-r--r--  1 12       10            696 Jul 23 22:25 birdisba.txt
    -rw-r--r--  1 12       10         233981 Jul  7 21:45 joel.lzh
    -rw-r--r--  1 12       10           1137 Jul  7 21:39 joel.txt
    -rw-r--r--  1 12       10         292665 Jun 25 22:39 moglie.mpg
    -rw-r--r--  1 12       10            439 Jun 25 22:39 moglie.txt
    -rw-r--r--  1 12       10         244095 Sep 18 12:42 mpegplay-020792.lha
    -rw-r--r--  1 12       10         368955 Sep 23 00:30 mpegplay.zoo
    -rw-r--r--  1 12       10         721801 Jun  3 23:42 mpgmovie.lzh
    -rw-r--r--  1 12       10            368 Jun  3 23:47 mpgmovie.txt
    -rw-r--r--  1 12       10         978660 Sep 13 17:35 raiders.mpg
    -rw-r--r--  1 12       10         250937 Jul  4 11:38 rom.mpg
    -rw-r--r--  1 12       10            951 Jul  4 11:39 rom.txt
    -rw-r--r--  1 12       10        1534405 Jul  3 13:42 sukhoi.mpg
    -rw-r--r--  1 12       10            342 Jul  3 13:48 sukhoi.txt
    -rw-r--r--  1 12       10         414427 Oct  2 21:45 tuttif3d.lzh

    Please contact this ftp-site for files before e-mailing to me !!!

-------------------------------------------------------------------------------
 V.3 |
------

    There is an MPEG archive site at:

      toe.cs.berkeley.edu (128.32.149.117) in the directory /pub/multimedia/mpeg

    Here is the current list from /pub/mpeg:

    -rw-r--r--  1 0        0            3243 Nov 16 20:48 README      [See chapter III.3]
    -rw-r--r--  1 0        0          502473 Nov 16 17:59 birdisba.mpg
    -rw-r--r--  1 0        0          180963 Nov 16 17:59 birdshow.mpg
    -rw-r--r--  1 0        0          206417 Nov 16 17:59 birdwalk.mpg
    -rw-r--r--  1 0        0           94959 Nov 16 17:59 f16.mpg
    -rw-r--r--  1 0        0          315038 Nov 16 17:59 flight.mpg
    -rw-r--r--  1 0        0           53411 Nov 16 17:59 micky.mpg
    -rw-r--r--  1 0        0          292665 Nov 16 17:59 moglie.mpg
    -rw-r--r--  1 0        0          116251 Nov 17 10:03 mpeg-1.0.tar.Z
    -rw-r--r--  1 0        0           24657 Nov 16 17:59 perpetu5.mpg
    -rw-r--r--  1 0        0          364256 Nov 16 17:59 qume.mpg
    -rw-r--r--  1 0        0          250937 Nov 16 17:59 rom.mpg
    -rw-r--r--  1 0        0         1534405 Nov 16 17:59 sukhoi.mpg

    Please contact this ftp-site for files before e-mailing to me !!!

-------------------------------------------------------------------------------
 V.3 |
------

    Gatz & Hartman BBS is now reachable via ftp, between 18.00 - 6.00 german time.
    Login as 'gast', then look for IBM-Files under File-Sector 14 : IBM_g_und_h

      zelator.in-berlin.de (192.109.42.11)


===============================================================================
 VI |  MAIL-ACCESS (PD-Software and movies)
===========================================

    You can retrieve the following files via e-mail. Just
    put a 'x' between the brackets and send the list back
    to me.


    ---- MPEG-UTILITIES ----

    MPEGDOS.ZIP      22183  11-16-92     ( )
    MPEGWIN.ZIP     209297  11-16-92     ( )
    MPEG-1.0.TAR.Z  116251  11-20-92     ( )


    ---- MPEG-MOVIES ----

    BIRDISBA.MPG     502473 10-19-92     ( )
    BIRDSHOW.MPG     180963 06-04-92     ( )
    F16.MPG           94959 06-04-92     ( )
    FIMPSY.MPG       281960 10-19-92     ( )
    FIMPSY50.MPG     240029 10-19-92     ( )
    FLIGHT.MPG       315038  5-25-92     ( )
    JOEL.MPG         285388 10-19-92     ( )
    MICKY.MPG         53411  8-27-92     ( )
    MOGLIE.MPG       292665 11-17-92     ( )
    QUME.MPG         364256 06-02-92     ( )


    Please choose one format you like to get the files in.

    ( ) As splitted, uuencoded tar-file (pieces < 64k)
    ( ) As splitted, uuencoded zip-file (pieces < 64k)
    ( ) As uuencoded tar-file
    ( ) As uuencoded zip-file
    ( ) As tar-file
    ( ) As zip-file

    Please request only ONE file per sended list !!!


===============================================================================
 VII |  RETRIEVED MAIL
======================

    From: [e-mail]
    Date: Mon Oct 19 14:48:43 1992

    Philips CD-I wird ab Anfang naechsten Jahres offiziel Full-Screen,
    Full-Motion Video koennen. Basis sind MPEG-komprimierte Videos. Die
    benoetigte Hardware-Erweiterung basiert auf C-Cube, bin aber nicht
    sicher. Kompression kann softwaremaessig erfolgen. Software existiert
    fuer SUNs im CD-I-Entwicklerpaket (n x 100.000 DM). Die Rechenzeiten
    fuer die Komression liegen bei 1:60 bis 1:400, also nichts mit
    Realzeitkompression.

    Intel's DVI-Technik kann noch kein MPEG (und das wird wohl auch noch
    einige Zeit so bleiben).

    Roman M. Jansen Winkeln                 Technical Director
    HQ Multimedia-Systeme GmbH              EMail   [e-mail]
    Feldmannstrasze 87                      Phone   [phone]
    D-6600 Saarbruecken                     Fax     [phone]


    [ For our english-folks: He is explaining that Philips will publish a    ]
    [ CD-I packages based on MPEG in spring 93. It requieres addiontional    ]
    [ Hardware, the software cost about 60.000 $, but does no real-time-     ]
    [ compression. Anyway, it will be the first system that integrates MPEG. ]

    ---------------------------------------------------------------------------

    From: [e-mail] (KETAN DASHARATH PATEL)
    Subject: Re: Xing's SW, Really MPEG Compression?
    Date: Thu Nov 19 13:20:35 1992

    Unfortunately, it is true. XING data is NOT true MPEG and in
    fact does a lot of dubious things with its Inverse DCT.

    XING data is simply a sequence of I-Frames (i.e. no interframe
    compression is done, no motion vectors, nothing).
    This amounts to little more than a sequence of JPEG type images.

    Ketan Patel
    [e-mail]


===============================================================================
 VIII | NEWS
============

    The MPEG-II-draft is about to arrive next week. It will take me a while to
    put the changes into this FAQ.

    ---------------------------------------------------------------------------

    [e-mail] wrote [and presents hereby something very
                                  interesting, something that we all
                                  like to see running !!!]

    We have developed a software MPEG decoder. It handles MPEG data that
    conforms to the draft standard as of Dec 1991. It has been alpha released
    last week and will be released to the general public sometime next week if
    I can get it polished in time.

    If you would like to recieve more information on how to get it, subscribe
    to the mailing list [e-mail] by doing the following:

    Send mail to:         [e-mail]

    with the single word ADD or DELETE in order to join or leave the mailing
    list.

    DO NOT SEND JOIN/LEAVE REQUESTS TO MPEG-LIST, SEND THEM TO MPEG-LIST-
    REQUEST.

    [See chapter III.3 as well]

-----snipp-----------------snipp-------------snipp----------sniopp---------
-----snipp-----------------snipp-------------snipp----------sniopp---------
-----snipp-----------------snipp-------------snipp----------sniopp---------